A wide array of products and services are accessible through the Internet and the World Wide Web (“Web” or “WWW”). For example, a Web user can shop, get traffic conditions, read product reviews, and compare products on-line. However, there are many types of services that are still not available through the Web. While a Web user may be able to find a restaurant in their particular area, for instance, they may be unable to determine whether that restaurant has seating available at a particular time on a particular night. Likewise, if a user owns a business, they may be interested in knowing if a vendor has a particular item in stock. If more than one vendor has the item in stock, the business owner may be interested in knowing which vendor has the item for the lowest price and which one can deliver the item fastest. Users are unable to perform such tasks using services currently available on the Web.
Services like those described above do not yet exist because there are no standards in place for integrating proprietary information like available restaurant seating, vendor inventory, prices, and delivery times, and other such information. After all, each vendor most likely has a unique way of describing the items or products they sell. Moreover, it is very difficult to develop computer program code necessary for integrating such disparate data and services. However, emerging technologies, such as the extensible markup language (“XML”), make the task of describing disparate types of data in a consistent way much easier. Moreover, new application development and execution platforms can help developers create and deploy distributed applications quicker and easier than ever before.
One development and execution platform that helps software developers to create and deploy distributed applications is the Microsoft® .NET platform from Microsoft® Corporation of Redmond, Washington. The Microsoft® .NET platform is an application programming and execution platform that provides write-once, compile-once, run-anywhere application development. Microsoft® .NET platform applications may be created in any language as long as they are compiled by a compiler that targets the Microsoft® .NET universal runtime (“URT”), also known as the common language runtime engine. Such a compiler compiles .NET applications into intermediate language (“IL”), rather than directly into executable code. IL is a platform-independent and central processing unit (“CPU”)-independent intermediate language. IL is a much higher level language than most CPU machine languages.
To execute a .NET platform application, the compiled IL is interpreted, or “just-in-time” compiled, by the URT into native machine instructions. The native machine instructions can then be directly executed by the CPU. Because IL is CPU-independent, IL can execute on any CPU platform as long as the operating system running on that CPU platform hosts the Microsoft® .NET URT. Applications compiled into IL need the URT to execute, and are called “managed code” applications. By contrast, code that does not need the common language runtime to execute, such as today's Win32 applications, are called “native code” applications.
The Microsoft® .NET platform also includes a base library that comprises a large set of class libraries and services. These libraries and services provide access to the features of the URT, and other high-level services, so that software developers do not have to code the same services repeatedly. For instance, classes may be offered to expose hypertext transfer protocol (“HTTP”) clients and servers, generic containers like arrays and dictionaries, and other types of classes previously available only through language-specific extensions.
The Microsoft® .NET platform also provides technologies to support rapid software development. For instance, in the Microsoft® .NET platform, all application services are offered via a common object-oriented programming model. This is unlike previous development and execution environments where some operating system facilities are accessed via dynamically linked library (“DLL”) functions and other facilities are accessed via component object model (“COM”) objects. Moreover, the Microsoft® .NET platform provides consistency in error-handling. When programming Microsoft® Windows® in a traditional fashion, some functions report Win32 error codes, some return HRESULTS, and some raise exceptions. In the Microsoft® .NET platform, all errors are reported via exceptions. This greatly simplifies reading, writing, and maintaining code.
In order to access management information about other applications and devices, Microsoft® .NET applications need access to instrumentation data, such as the data provided by Microsoft® Windows Management Instrumentation (“WMI”). WMI is the Microsoft® Corporation's implementation of the Distributed Management Task Force's (“DMTF”) Web-Based Enterprise Management (“WBEM”) initiative. WMI is a set of system services and programming interfaces that allow applications to expose instrumentation data in a consistent way. By exposing instrumentation data in a consistent fashion, management applications can be written to a single application programming interface (“API”). WMI also provides a set of services, such as remoting, asynchronous access, and scripting, that allow applications and management tools to better access and serve management data without requiring information providers to explicitly support those features. Additionally, WMI services also include a standard query language for management objects, event publication and subscription, and standard event filtering and aggregation.
WMI currently runs in native code outside the .NET platform. Therefore, WMI does not have access to instrumentation data offered by applications executing in managed code. Because WMI is a management platform, in order to be effective it must be able to access data regarding all instrumented objects and applications, including those executing in managed code within the .NET platform. Additionally, WMI should be able to easily obtain instance information on object classes exposed from within the .NET platform, and to write properties and execute methods on instances of these classes. In order to be truly effective, provision of instrumentation data from the .NET platform to WMI should be easily implemented during or after code development and deployment.
Therefore, in light of the above, there is a need for a method and system for easily providing instrumentation data, including class, instance, and method information, from applications executing within a managed code environment, such as the .NET platform, to an instrumentation data source, such as WMI. Moreover, provision of instrumentation data should be accomplished through an easy-to-use interface that allows code to be instrumented during or after development.